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Abstract 

This document describes the job priority computation and usage in DSS Server which affects 
the execution order of user requests. 
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Role of job priority in job execution 

DSS Server creates job objects for every user requests that can not be immediately serviced. 
Processing units within DSS Server execute jobs in a pipeline architecture (refer to the server 
internal architecture document for details on the pipeline architecture). Each processing unit 
contains a hierarchical queue (we will call this a station) and a pool of threads that service the 
queues. The jobs are placed within a queue based on its priority while the threads available to 
service a job will pick the first job within a queue that is selected using the servicing schemes. 

Following two sections describe the process of entering the job into a particular queue of a 
processing unit 



1. 1 Entering jobs into a queue 

Every processing unit in DSS Server contains a hierarchical queue, which is organized as a tree. 
Typical processing units contain only a two-level hierarchy (except for the processing units 
containing the DSSQueryExecutionTask which require three-level hierarchy where the first level 
split by the warehouse dbc type). The leaf nodes represent basic FIFO queues, while all other 
nodes are a collections of queues, or queue sets. 




Figure 1 . Hierarchical queue structure in a typical DSS Server PU. The variables a, b, c, d and e are 
positive integers and Inf stands for infinity. 



MSIQReturnStatus MSIHierarchicalQ::Enqueue(JOB_TYPE *Uob, unsigned long iMilliseconds = 
gclnfiniteTimeOut){ 

int apriority = mPrioritySchemeObject->Ca!culatePriority(iJob); 
MSIQReturnStatus aRC; 

for(int aSubQ = 0; aSubQ < mSubQueues; aSubQ++){ 
if(aPriority < mUpperBounds[aSubQ]){ 

aRC = mSubQ[aSubQ] -> Enqueue(iJob, iMilliseconds); 
break; 

} 

} 

if(aSubQ >= mSubQueues) { 

aRC = mSubQ[mSubQueues-1 j -> Enqueue(Uob, iMilliseconds); 

} 

return aRC; 
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When a job needs a particular task to be done, the JobExecutor inside DSS Server finds a processing 
unit which can perform that task, and hands over the job to the processing unit by way of the 
MSIPU: :Enter(MSIJob *i Job) method. The implementation of this method in turn, calls the 
MSMerarchicalQ::Enter(MSIJob *to leaf within 

its station. This method involves computing the job priority to decide which queue or queue set 
should the job be placed in. At the leaf nodes, the MSIBasicQ::Enter(MSIJob *iJob) method 
actually enters the job at the tail end of the FIFO queue. As shown below, at every intermediate 
node, each of its subqueues is associated with a range of priorities. The priority computed at 
intermediate nodes indicates subqueue to enter the job into. 



1.2 Calculation of job priority 

The calculation of job priority at a QSet (MSIHierarchicalQ) node can be configured differently 
for different nodes to achieve different objectives in job prioritization. An example would be to 
split jobs at RootQ based on project and at the next level splitj obs based on two user groups. 
With this configuration, an administrator can allocate resources such as server threads and 
database connections for each projecta nd user group independently, and specify their servicing 
schemes as desired. This configuration can be achieved by specifying a priority function at 
RootQ, which ignores every priority variable other than project and returns the project id as the 
job priority, which will be used to index into the Qset and enter the job into the corresponding 
node below RootQ. 



Figure 2. Configuring queue structure so that at the first level, the job is prioritized based on the 
project and at the second level it is prioritized based on the user group. Note that at this stage, the 
queue structure represents only a means of categorization. Priority ranges associated with the 
queues together with servicing policies determine the real priorities between queues and the order in 
which jobs are processed in a PU. 




MSrBastCQ 



[SIHierarchicalQ 



(SIBasicQ 
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Implementation of job priority 



1.3 MSUobPrioritySchemeObject 

To implement different priority calculations at different nodes of the hierarchical queue,e very 
MSIHierarchical node object contains a MSUobPrioritySchemeObject, which provides the 
CalculatePriority method. MSIJobPriorityScheme is an abstract base class which only provides 
the Calculatepriority interface method. In DSS Server ,t here are several classes derived from 
MSUobPrioritySchemeObject ,w hich implement the calculate priority in various ways. There are 
several predefined classes derived from MSUobPrioritySchemeObject defined in the MSIPU.h as 
described below. For example MSIJobPrioritySchemeObjectRandom is equivalent to entering the 
job into one of the queue set or queue selected randomly. 

Class Config Manager; // forward declaration 

template <class JOB_TYPE> class MSUobPrioritySchemeObject { 
protected: 

int mType; 
public: 

typedef int PCFunc(JOB_TYPE *Uob); 

MSIJobPrioritySchemeObject(int iType = -1) :mType(fType) {}; 

virtual int GetType() { return mType; } 

virtual ~MS1JobPrioritySchemeObject() {}; 

virtual int CalculatePriority(JOB_TYPE *iJob) = 0; 

virtual bool lnit(ConfigManager*iConfig, String List & iPath) = 0; 

virtual MSIJobPrioritySchemeObject<JOB_TYPE> *Clone() = 0; 

}; 

en urn MSIJobPriorityScheme { 

gcJobPrioritySchemeDefault = 0, 
gcJobPrioritySchemeUserSupplied = 0, 
gcJobPrioritySchemeRandom, 
gcJobPrioritySchemeObjectMapBased 

}; 



class MSIJobPrioritySchemeObjectRandom: public MSIJobPrioritySchemeObject<MSIJob> { 
public: 

MSIJobPrioritySchemeObjectRandomO: 

MSIJobPriorttySchemeObject<MSUob>(gcJobPrioritySchemeRandom) Q; 
int CalculatePriority(MSIJob *Uob){ 

return rand(); 

} 

MSIJobPrioritySchemeObject<MSIJob> *Clone{) { 

return new MSIJobPrioritySchemeObjectRandom(); 

}; 

bool lnit(Config Manager *iConfig, StringList & iPath){ 
return true; 

} 

">; 

class MSIJobPrioritySchemeObjectUserSupplied: public MSIJobPrioritySchemeObject<MSIJob> { 
public: 

MSIJobPrioritySchemeObjectUserSupplied(): 

MSIJobPriorttySchemeObject<MSUob>(gcJobPrioritySchemeUserSupplied){}; 
int CalculatePriority(MSIJob *Uob){ 
return Uob->GetPriority{); 

} 

MSIJobPrioritySchemeObject<MSIJob> *Clone() { 

return new MSIJobPrioritySchemeObjectUserSupplied(); 

}; 

bool lnit(Config Manager *iConfig , StringList & iPath){ 
return true; 

} 

}; 
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1.4 Creation of MSIJobPrioritySchemeObjects 

Note that the MSIJobPrioritySchemeObject interface also includes two more methods, namely 
Init and Clone methods. The InitO method is used to initialize the object with a configuration 
settings specific to that node. For example, this would be used to which path the object is 
attached to, so that any other configuration information can be obtained from the ConfigManager. 
The Clone() method is used by MSIPU in creation of these objects at the MSIHierarchicalQ 
nodes. MSIPU is given an array of predefined prototype objects, one of each type, from which 
MSIPU clones alio ther objects as the Q structure is being created. 

At the DSS Server startup time, based on the configuration specified, config manager creates the 
processing units with the required queue structure along with the MSIJobPrioritySchemeObjects at 
all MSIHierarchicalQ nodes. When there is no scheme specified, either the parent node's scheme 
is used or a default is selected as shown below. 

// extracted from MS I PU .cpp 
MSIPU::BuildHierarchicalQ(...){ 

// check if PriorityScheme parameter is specified at this node, 
// and if so store its type in IPriorityScheme 
if(IPriorityFunctionKeyFound){ 

// no PriorityFunction key found 

IPrioritySchemeObject = mPrioritySchemeObject[IPriorityScheme]->Clone(); 
IPrioritySchemeObject->init(ISubParameterTree); 

} 

else{ 

// no PriorityFunction key here but this is a QSet 
if(iParentPrioritySchemeObject) { 
// parent got hold of one, clone it 

IPrioritySchemeObject = iParentPrioritySchemeObject->CloneO; 
IPrioritySchemeObject->lnit(ISubParameterTree); 

} 

else { 

// parent had none: probably this is the root and has no PriorityScheme specified 
IPrioritySchemeObject = mPrioritySchemeObject[gcJobPrioritySchemeDefault]->Clone(); 
IPrioritySchemeObject->lnit(ISubParameterTree); 

} 

} 

} 



1.5 Proposed implementation according to specifications 

The above design of a queue structure with MSIJobPrioritySchemeObject at each node is general 
enough to implement vastly different ways of determining priroities of a job by way of overriding 
MSIJobPrioritySchemeObject::CalculatePriority() method in derived classes of 
MSIJobPrioritySchemeObject. It even allows for different ways of computing priority at 
different nodes, even though it is not desirable in general. DSS Server specification document 
fixes many of the dimensions for the sake of simplicity and manageability. 

Here is a summary of the specification regarding job priorities. Job priorities are calculated based 
on a number of factors relevant to the job. Some of the factors are allowed to interact nonlinearly 
in determining the priority while others are assumed to interact linearly. DSS Server allows for 
the administrator to selectw hich factors interact nonlinearly and which ones interact linearly. 
This is selected through a configuration wizard such as the one included in DSS Server 
Administrator product. Examples of factors that could interact nonlineraly are: project, user 
group, report type, initial report priority, time period and report cost as determined by a linear 
combination of other factors. The factors that are assumed to interact linearly are those that can 
be measured quantitatively for any job. Examples of linear factors are: historical report cost, 
estimated report cost, number of database queries, size of result set etc. Each linear factor is 
associated with a weight, and a combined report cost is computed as a weighted linear 
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combination of all the linear factors. This combined report cost is one of the factors allowed to 
interact nonlinearly in determining the job priority. The nonlinear factors determine the the job 
priority through a priority map (or table) whose input dimensions are all the factors allowed to 
interact nonlinearly and the entry in the map giving the job priority. The map representation to 
determine job priority is chosen because it is noto nly powerful enough to represent any kind of 
relationship between the input dimensions and the resulting priority, but also is convenient to 
define, store and communicate and efficient to calculate the priorities. 

Thus to compute the job priority, first the values of linear factors are computed for the job, their 
weighted linear combination is computed as a combined report cost. Then,t he priority map is 
looked up using the combined report cost together with all other nonlinear factors as input 
dimensions into the map. The map entry represents the priority for that job. 

Note that the priority map is allowed to be different at different nodes of a process unit and 
different across process units,a llowing for highly flexible priority configurations. In the current 
design,t he nodes contain a pointer to MSIJobPrioritySchemeObjectMapBasedo bject, which 
store a pointer to the priority map for that node. This allows for sharing the priority maps 
between nodes. 

Also, the weights in the weighted linear combination formula are allowed to be different at 
different PU's. This is done by storing the multiple lists of linear factor name along with its 
weight in a DSSProperty interface in the report instance itself. Each listc orresponds to a 
weighted linear combination formula. These lists are created in the report instance by looking up 
the report definition, server definition and projectd efinition the former parameters overriding the 
latter in case of multiple definitions containing these parameters. 

To define the priority calculation function as described above, one would specify the 
PriorityScheme parameter to the node as gcJobPrioritySchemeObjectMapBased. The 
MSIJobPrioritySchemeObjectMapBased class is as defined below. Individual nodes would get 
the map information from ConfigManager.C onfigManager would have access to all the 
configuration information, including the priority maps defined by the administrator at different 
nodes. Note that it allows the map to be shared across processing units and nodes as configured, 
without having to duplicate them. 

II MSIConfig.h 

class MSIJobPrioritySchemeObjectMapBased: public MSUobPrioritySchemeObject<MSIJob> { 
protected: 

ConfigManager *mConfig; // Config has all configuration info 
String List mPath; // path to the SubQ including the name of the PU. 

Int mNonlinearFactors; 
Int *mNonlinearFactor; 
Int ANonlinearFactorMaxValue; 
public: 

MSIJobPrioritySchemeObjectMapBased (): 

MSIJobPrioritySchemeObject<MSIJob>( gcJobPrioritySchemeObjectMapBased) {}; 
int CaIculatePriority(MSIJob *iJob){ 

void 'aPriorityMapPtr ~ mConfig->GetPriorityMap(mPath); 

intaValue; 

int aNonlinearFactorMaxValue = 1 ; 

for(int aNonlinearFactor = mNontinearFactors-1; aNonlinearFactor >=0; aNonlinearFactor-){ 
// the combined report cost is one of the nonlinear factors 
// all nonlinear factors are computed within MSI Job module 
aValue = iJob->GetFactorVa!ue(mNonlinearFactor[aNonlinearFactor]); 
aPriorityMapPtr = (void *) ((int *)aPriorityMapPtr + aNonlinearFactcr MaxValue*aValue); 
aNonlinearFactorMaxValue *= mNonlinearFactorMaxValue[aNonlinearFactor]; 

} 

return *((int *) aPriorityMapPtr); 

} 

MSIJobPrioritySchemeObject<MSIJob> *Clone() { 

return new MSIJobPrioritySchemeObjectMapBased (); 
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}; r 

bool lnit(ConfigManager *iConfig, StringList & iPath){ 
mConfig = iConfig; 
StringListCopy(mPath, (Path); 
return true; 

} 

}; 



1.6 Changing priority after job is entered into queue 

Once the job is entered into a queue, its priority is no longer relevant, as the servicing schemes dictate in 
which order jobs are serviced within a queue (servicing schemes are described in the next section). Hence, 
changing its priority would not affect the order in which it is serviced. If an administrator wishes to 
process the job earlier or later than it would have otherwise (which is usually thought of as changing the 
priority of a job), DSS Server allows for severalc ommands which allow flexible job movement within or 
across queues. 

The DSS Server commands that allow moving a job within a basic queue are: 

• MoveAheadByOne: moves job ahead by one (no effect if there is no other job in front of this one) 

• MoveBehindByOne:m oves job behind by one (no effect if there is no job behind this one in the 
queue) 

• MoveToFront: moves the job to front of the queue 

• MoveToBack: moves the job to the back of the queue 

For the above commands,t he queue need not be supplied by the client,a s DSS Server will find the queue 
in which the job is waiting and carry out the command within that queue. 

The DSS Server commands that allow moving a job across queue are: 

• MoveToQueue:g iven a job and the new queue name (which could be a hierarchical queue), DSS 
Server will find the queue in which the job currently is waiting, remove from there and enter it into the 
new queue specified. 
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Job Servicing Schemes 



Job servicing schemes are mechanisms to control how jobs are serviced. So, the servicing scheme is 
applied when these resources are allocated to the jobs for their processing. That is, whenever all resources 
(such as server thread and database connections) become available to process a job, which job would they 
be allocated to next. Notice that the threads are the primary resources in a process unit, which does not do 
tasks involving heavy database usage. One exception^ s the case of a database process unit that executes 
warehouse queries, where database connections (which are paired with the thread that created them) are the 
primary resource. 

Given the fact that jobs are always serviced first-in-first-out within a queue, the job-servicing scheme in 
effecta pplies to selection of queues. That is,a ny time a resource is available to process a job, it is 
sufficient to selecta queue to service next. Thus,s ervicing schemes are attached to a Qset, where there is 
a choice of queues to selectf rom (whenever we decide to process jobs from that Qset). It follows that 
every Qsetn ode in the process unit hierarchy, contains a servicing scheme specified to it. Accordingly, 
every MSIHeirarchicalQ has a mSubQServicingScheme data member, of integer type that specifies the 
servicing scheme from an enumeration of available servicing schemes. The available choices of servicing 
schemes defined below. 



en urn MSISubQServicingScheme { 

gcSubQServicingSchemeUndefined = -1 , 
gcSubQServicingSchemeDefault = 0, 
gcSubQServicingSchemeFixedThreadCooperative = 0, 
gcSubQServicingSchemeFixedThread, 
gcSubQServicingSchemeHighestPrioriryFirst, 
gcSubQServicingSchemeWeightedShare 



1.7 Units of independent resource allocation and control 

In a process unit,t he unit at which resources can be independently allocated and controlled are those 
Queues and Qsets that have fixed servicing schemes. A Qset that specifies a servicing scheme other than 
fixed implies that the subqueues within it are serviced collectively. This also implies that resources 
should be allocated collectively. Thus, the current design allocates independent thread pools to all Qsets 
that have servicing schemes other than fixed. At the Qset nodes that specify a fixed servicing scheme,t he 
subqueues within it are serviced independently on their own, and thus have their own collection of thread 
pools. In this case, we associate the pool of subqueue thread pools to the Qset, to conveniently add or 
remove threads from the QSet. As an example, we show the servicing schemes at each node and the 
resulting thread pool hierarchy. MSIBasicThread pools is a collection of MSIThreads. 
MSIHierarchicalThreadPool is a collection of MSIBasicThreadpools. 



}; 



WeightedShare 
MSI basicThreadpool 




[BasicThreadpool 
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1.8 Job processing according to a servicing scheme 

In our process unit design, the job processing in a process unit takes place via the MSIQTask class. 
MSIQTask::Run() method is an encapsulation of the task to be performed within the process unit whenever 
the processing resources are available. Typically, the server threads are the resources, which come from a 
hierarchical thread pool within the process unit. The threads within a thread poola re given an object of 
MSIQTask,w ith the MSIBasicQ node or an MSIHierarchicalQ node which they service. The method 
GetNextJob implements checking all subqs from a given level for a job. It returns timeouti f there is no 
job after a scan of all basic q's under the given level. 

void MSIQTask::Run(){ 

// Code deleted: setup preferred path if any and 

// setup current weights for all subqueues with weighted share 

while(!lsCanceled()){ 
if(mPreferredSubQ){ 

IRC = GetNextPreferredJob(mPreferredSubQ, 0, 

mSubQlndexBelowRxed.begin(), &IJob, &IQ); 
IRC = mPreferredQ->WaitForNext(&IJob, gcMSIQMaxWaitTimeForNexUob); 
if(IRC==gcMSIQTimedOut){ 
continue; 

IRC = GetNextJob(mQ, 0, mFixedSubQ Index. begin(), 
rnNonPreferredSubQIndex.begin(), true, &IJob t &IQ); 

if(IRC == gcMSIQTimedOut){ 
ITimedOut = true; 
continue; 

} 

// else got job in a non preferred Q 

} 

// else got job in preferred Q 

} 

else{ 

// no preferred Q 

IRC = GetNextJob(mQ, 0, mFixedSubQlndex.begin(), 

mNonPreferredSubQlndex.begin(), true, &IJob, &IQ); 
if(IRC ~ gcMSIQTimedOut){ 

ITimedOut = true; 

continue; 

} 

} 



mCheckGovernersTask->SetJob(IJob); 
mCheckGovernersTask->Run(); 

if(mCheckGovernersTask->GetStatus() == MSIJobTask::JOBTASK_ABORT) ; 
} 

else{ 

IJob->AddRef(); // we need the job to be alive till we are done with it 

Uobld = IJob->Getld(); 

Uob->SetPUStart(mOwnerld); 

try{ 

mProcess->SetJob(IJob); 

mProcess->SetThread(GetThread()); 

mProcess->Run(); 

} 

catch(...){ 

//MSIQTaskTraceLTEXTC'ERROR: task execution for job threw an exception"), 
Uobld, IQ); 
} 

mProcess->SetThread(NULL); 
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} 

Uo^>SetPUExit(mOwnerld); 

IQStatus = IQ->Dequeue(Uob); 

if(IQStatus == gcMSIQSucceeded) Uob->Re!ease(); 

IThreadlnfo.SetJobld(-l); 

} // end of while 

} 



1.8.1 FixedThreadCooperative 

When the servicing scheme is FixedThreadCooperative, the MSIQTask then also contains a PreferredSubQ 
path, which is the path down the hierachy along which all nodes specify fixed thread cooperative. In this 
case, threads attempt to get a job from the preferred q/qset first and if failed, w ill attempt to get from any 
queue in the Qset. The method GetNextPreferredJob implements checking the preferred subq path for any 
job, which returns timeout if there is no job after one scan. 

Note: This servicing scheme is meant to fix threads to subqs, but let them service other subq's at the same 
level only when there is no job in the subq to which the thread is fixed. Assume the following scenario. 




A Qset contains two subqs, which are basic queues. The number of threads in the threadpoola re eight,o ut 
of which four are fixed to first and the remaining four are fixed to the second. Suppose, at a particular 
instance the first subq had no jobs, and the four threads fixed to started processing jobs from the second 
subq which had a large number of jobs. Suppose a job arrives in the first subqueue during which time all 
four threads are still servicing the jobs they picked up from the second subq. At just such a time,o ne of 
the threads fixed to the second subqf inishes one of the jobs and becomes available. Which subq will it 
pick the next job from? 

There are two different interpretations of this servicing scheme which answer this question differently. 
The first interpretation is that the threads are fixed to the preferred subq they are servicing and as long as 
there are jobs in that subq, they do not attempt to take jobs from any other queue. According to this, the 
answer to the above question would be that the thread belonging to the second subq would take its next job 
from the second subq. 

The second interpretation of this servicing scheme is that the threads are notf ixed to the subq permanently, 
rather they are dynamically assigned to a subq's according to a fixed proportion given in the configuration. 
According to the above thread (any thread from the second subq that becomes available next),g ets assigned 
to the first subq as soon as there is a job in the first subq. So, the threads would change their preferred 
queue to optimize in the situations described above. This makes more sense as automatic load balancing 
within a process unit. 

In our current implementation, we have chosen to use the firsti nterpretation and minimize the 
implementation complexity. 

1.8.2 WeightedShare 
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When the servicing scheme is weighted share, the subqueues within the Qset also incorporate weights and a 
running count of number of jobs serviced at each subqueue. The method GetNextJob checks all subqs at 
the given levelf or a job and implements the running weight counter increments in a queue when returning 
a job from a that queue. The running counts are resett o zero when last subq count at any levelr eaches its 
maximum value. 



1.8.3 HighestPriorityFirst 

The GetNextJob method implements checking all subq's at a given levelf or a job, in the order of highest 
priority to lowest priority subq. 
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